Columbia Kermit/kermit.zip/newsgroups/misc.19990725-20000114/[e-mail] _Thu Jan 13 19:55:06 2000.msg

Internet Message Format | 2020-01-01 | 4KB

Return-Path: <[e-mail]>
Received: from newsmaster.cc.columbia.edu (newsmaster.cc.columbia.edu [128.59.59.30])
    by watsun.cc.columbia.edu (8.8.5/8.8.5) with ESMTP id TAA26067
    for <[e-mail]>; Thu, 13 Jan 2000 19:55:06 -0500 (EST)
Received: (from news@localhost)
    by newsmaster.cc.columbia.edu (8.8.5/8.8.5) id TAA29286
    for [e-mail]; Thu, 13 Jan 2000 19:50:42 -0500 (EST)
X-Authentication-Warning: newsmaster.cc.columbia.edu: news set sender to <news> using -f
From: [e-mail] (Frank da Cruz)
Subject: Case Study #6: Streaming
Date: 14 Jan 2000 00:50:40 GMT
Organization: Columbia University
Message-ID: <85lrt0$sj3$[e-mail]>
To: [e-mail]


One of the goals for C-Kermit 7.0 was to make Kermit file transfer
comparable in speed to FTP on TCP/IP connections.  Early experiments using
long packets and large window sizes gave excellent results when certain
platforms were involved.  But with other platforms, the results were
discouraging -- throughput was only about 10% of what we expected.

To make a rather long story short, this severe degredation in speed was
caused not by anything in Kermit itself, but rather by the underlying
TCP/IP stack when it implemented certain heuristics such as the Nagle
Algorithm and/or Delayed ACK.  These are triggered when the file receiver
sends a Kermit ACK (acknowledgement packet), which is quite short.  The
TCP stack hangs on to it for some amount of time -- say 200 milliseconds --
before letting it go, in hopes that by then it will have something more
to transmit.

But 200 milliseconds is a long time on a ten-million-bit-per-second
connection.  It's long enough to transmit 2,000,000 bits of data.  Once
the file sender is blocked waiting for a delayed Kermit ACK, which happens
as soon as its send window fills up, throughput takes a nosedive.

The only way around this problem is for the file receive NOT to send ACKs.
Then the file sender can "stream" the data continuously -- just like FTP
does.

But if the file receiver doesn't send ACKs, there can be no error
recovery.  Errors can be detected, but if any occur, they are fatal.  But
since it's a TCP/IP connection there are not going to be any non-fatal
errors, by the very definition of TCP.

So we introduced streaming in the latest round of Kermit releases:
C-Kermit 7.0, G-Kermit 1.00, Kermit 95 1.1.17, and MS-DOS Kermit 3.16
(still in Beta).  Streaming is used automatically when, both Kermit
programs know about it and the Kermit program that made the connection
tells the Kermit on the far end that the connection is reliable; the two
Kermits agree to stream.  And when they stream, transfers go fast.

Exactly how fast depends on how you made the connection.  If it's a Telnet
or Rlogin connection, it's going through several layers of overhead that
FTP doesn't have: the Telnet or Rlogin server -- and the pseudoterminal
and driver -- on the far end.  The amount of overhead depends on the
implementation.

On the other hand, if you have a direct socket-to-socket connection
between two Kermit programs, you should get about the same speed as FTP.
How do you get a direct socket-to-socket connection?  One way, which is
not terribly convenient, is described on page 127 of "Using C-Kermit" (the
"set host *" method).  But now there's a better way: the Internet Kermit
Service (IKSD).  We'll talk about that in a future installment, but in the
meantime you can visit:

  http://www.columbia.edu/kermit/cuiksd.html

for an introduction.

Streaming can be used not only on TCP/IP connections, but any other
reliable transport, such as X.25.  But it is not -- and should not be --
used on serial connections; even if you are using error-correcting modems,
there is no guarantee of reliable transport between the modem and the
application -- for example, there can be flow-control failures.

For more about streaming, read Section 4.20 of the ckermit2.txt file.

- Frank